SQL server 2008 : Handling Errors (part 1)

However, since the development of SQL Server 2005, you can use a TRY... CATCH block to handle errors. This block tries to run your code, and, if an error occurs, SQL Server begins execution of code that handles this error. This feature offers database developers great control of the flow of code and also lets you retrieve customizable information about the raised error.

@@ERROR Function

The @@ERROR function returns the error ID number generated by the most recent statement executed by a user. If the value returned is zero, then no error occurred. This function is available in all versions of SQL Server, and it’s the only way to handle errors in version 2000 and previous of SQL Server.

For each statement of your code that SQL Server executes, the value of @@ERROR is cleared and reset. This means that you must check the value of this function immediately following each statement that is verified or save its value to a local variable that can be checked later.

Because of this behavior, codes developed using @@ERROR are generally complex and full of verifications using IF statements. Also, there are some errors that terminate execution when raised, which @@ERROR can’t handle, since the code that refers to this function isn’t executed. The following code shows the use of @@ERROR in a transaction in the AdventureWorks2008 database.

--Executing a defective INSERT
INSERT INTO [Production].[ProductCategory](Name, ModifiedDate)
VALUES ('Custom Category 1', '2008-20-20');

--Print the @@ERROR value
RAISERROR('The number of the error is: %u', 16, 1, @@ERROR)

An error should be returned since the date informed in the INSERT statement doesn’t exist. The following code shows the output of the execution:

Msg 242, Level 16, State 3, Line 1
The conversion of a varchar data type to a datetime data type resulted in an
out-of-range value.
The statement has been terminated.
Msg 50000, Level 16, State 1, Line 6
The number of the error is: 242

					  

--Executing two INSERT statements
INSERT INTO [Production].[ProductCategory](Name, ModifiedDate)
VALUES ('Custom Category 1', '2008-20-20');
INSERT INTO [Production].[ProductCategory](Name, ModifiedDate)

--Print the @@ERROR value
RAISERROR('The number of the error is: %u', 16, 1, @@ERROR)

Now, SQL Server will return interesting information. First, SQL Server will return the error of the first INSERT statement caused by the date value. Then, SQL Server will execute the second INSERT without problems. The output is as follows:

Msg 242, Level 16, State 3, Line 2
The conversion of a varchar data type to a datetime data type resulted in an
out-of-range value.
The statement has been terminated.

(1 row(s) affected)
Msg 50000, Level 16, State 1, Line 7
The number of the error is: 0

					  

@@ERROR has some tricky behavior: although there was an error in the first statement of your code, the second statement executes correctly. Because of the last successful statement, SQL Server clears the previous value of @@ERROR and sets its value to 0. To solve this situation, you should use a local variable to store the error number and IF statements to verify the possible errors that may arise.

Another important thing that you must be aware of is the retrieval of information about the error. The @@ERROR function doesn’t provide direct access to properties like the severity level or the text of a message.In this case, you have two options: you can define your own custom error message for each possible error that can arise in the code, or you can select the error information in the sys.messages catalog view and store it in local variables. Although the last option may sound nice, most of these messages will be useless to you, especially when system errors are involved. The following code shows why retrieving error information with an @@ERROR value and then raising it as an error might be useless for your application:

--Creating the local variables
DECLARE @num INT
DECLARE @text VARCHAR(255)
DECLARE @severity INT

--Executing a defective INSERT
INSERT INTO [Production].[ProductCategory](Name, ModifiedDate)
VALUES ('Custom Category 2', '2008-20-20');

--Setting the local variable value with the @@ERROR value
SET @num = @@ERROR

--Retrieving the error data
SELECT @text = text, @severity = severity FROM [master].[sys].[messages]
WHERE message_id = @num and language_id = '1033'

--Raise the custom error message
RAISERROR(@text, @severity, 1)

You can see that the last error raised by the code shows two NULL values in the text. Those are arguments that belong to the message and were not replaced with their values when the first error arose. As a result, this error message becomes useless to the application if you don’t know which parts are the arguments and inform them in the RAISERROR statement. In short, it’s too much work for too little a result.

Keep in mind that the best way to handle errors with the @@ERROR function is to use an IF statement and define custom messages according to the error ID number that you store in a local variable.